Cryptography and key management device and architecture

ABSTRACT

A method for operating a secure device having a plurality of mutually exclusive circuit zones, including a first circuit zone having a first level of security and a second circuit zone having a second level of security less than the first level of security, the method including unpacking a key exchange package including receiving a key exchange package in the second circuit zone, the key exchange package including encrypted key data and processing the encrypted key data using a content key in the first circuit zone to generate decrypted key data and storing the decrypted key data in the first circuit zone without disclosing the decrypted key data into the second circuit zone.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No. 13/937,919filed Jul. 9, 2013, which claims the benefit of U.S. ProvisionalApplications No. 61/669,171, titled “SHAMROCK: Self ContainedHigh-Assurance Micro Crypto and Key Management Processor,” and61/669,179, titled “Method for Securing Data using Hardware FunctionalGates,” both filed Jul. 9, 2012, the contents of which are incorporatedherein by reference.

STATEMENT AS TO FEDERALLY SPONSORED RESEARCH

This invention was made with government support under Contract No.FA8721-05-C-0002 awarded by the US Air Force. The government has certainrights in the invention.

BACKGROUND

This invention relates to a device and architecture for securecryptography and key management.

Modern cryptography offers a variety of schemes for the protection ofinformation at-rest on devices and in-transit among devices. Acryptographic scheme typically “scrambles” or “unscrambles” informationusing a data-permutation algorithm and a short cryptographic key. Thesecurity of the scheme depends on the properties of the algorithm andthe quality and secrecy of the key. Thus, cryptographic keys need to becreated and managed carefully. In particular, keys need to be protectedat-rest and in-transit, which itself calls for the use of variouscryptographic schemes.

Hardware implementations of cryptographic functions may exist today inhardware, for example as FPGA cores. There may also be special-purposesolutions that are coupled with applications and may implement some formof specialized key management. For example, HAIPE (High AssuranceInternet Protocol Encryptor) devices implement a protocol based on theInternet Protocol Security (IPSec) standard for establishing andsecuring Internet Protocol (IP) communication among devices.

Although many cryptographic schemes have been standardized andimplemented efficiently in software and hardware, these solutions arenot universally used or embedded in devices. In general, this is thecase due to two main reasons:

-   -   a. The lack of generic, easy-to-deploy, and easy-to-use        solutions for key management, and    -   b. The challenge of integrating various cryptographic and key        management components into a holistically secure design.

While individual cryptographic components exist and may be known to besecure, there is no known “recipe” for integrating different componentsinto secure designs that guarantee security of keys and otherinformation, at-rest and in-transit. It is in such integration thatmajor challenges exist and vulnerabilities are often times introduced.

SUMMARY

In one general aspect, a self-contained, integrated general-purposedesign and architecture for a cryptography and key-management solutioncan be realized as an integrated circuit core, such as, for example, aField Programmable Gate Array (FPGA) core or an application-specificintegrated circuit (ASIC) core.

The key management tasks may include operations such as creatingcryptographic keys, associating keys with their purposes, protectingkeys at rest in both volatile and non-volatile memory, making keysavailable for authorized encryptions and authorized decryptions,delivering keys securely to authorized remote devices, archiving keys,evolving keys with time, retiring keys, etc.

Some implementations attain high performance, low power, flexibility,and extensibility—all at the same time. This is achieved by implementingcertain, typically computationally demanding components, such as thestandard cryptographic functions, directly in hardware (for exampleusing VHDL), while other components, such as key management protocols,in a higher-level language, such as C, in a softcore micro-controllerinside the integrated circuit. The softcore micro-controller, allows fordifferent key management protocols and their extensions to be easilycreated for and deployed in the architecture, even after the integratedcircuit core is manufactured and integrated into an application. Thehardware implementations of the cryptographic components used by theapplication and by the key management components facilitate lower-power,higher-speed operations.

Embodiments of the architecture achieve assured security by separatingits internals into a number of physical regions (also referred to as“zones” or “circuit zones” in some examples), and tightly controllingwhich information flows from one region into another and how it does so.The separation among the different regions is enforced by hardware,through the physical layout of the regions and by their interconnectionsin the integrated circuit.

In some examples, a device has a dedicated region for storing andhandling long-term cryptographic keys of the device (such as the onesused for authenticating the device's identity), another region forstoring and handling short-term keys (such as the ones used for securingcommunication sessions), and yet another region for storing and handlinginformation that does not contain exposed secrets (such as encryptedkeys). The only physical paths from a region that handles cryptographickeys to the region that interfaces with the application is by goingthrough a “scrambler” circuit (also referred to as a “gate circuit” or“hardware functional gate” in some examples) such as a secure hashfunction or an AES encryption function. This restricted physicalconnectivity completely prevents a possibility of keys inadvertentlyleaking out due to a logical control flow problem in the design.

The hardware-enforced separations among the regions greatly simplifiesthe task of establishing and verifying security properties of the designand reduce the possibilities of a design bug or an attack compromisingthese security properties. In contrast, logical separation of regions,which uses logical “guards” to control and restrict the flow ofinformation among the regions, leaves the regions physically connectedand, thus, at some level, allow for a possibility that a malfunction oran attack will lead to an undesired flow of information from one regionto another, and to a security problem.

Key management operations often involve coordinated processing indifferent regions, with information flowing among them. In someexamples, the key management component allows for such coordinatedprocessing and the necessary flow of information to occur, despite thephysical separations among the regions.

The physical separation of the regions that handle keys from those thatdo not allows for the latter types to use memory that is external to theintegrated circuit. Such external memory may be less expensive than andnot be as much size-limited as the integrated circuit's internal memory.The device can protect confidentiality and integrity of the informationplaced in the external memory with encryption.

In some aspects, hardware functional gates include Elliptic KeyDiffie-Hellman cryptography gates, true and pseudo-random numbergenerators, signature verification gates, signing gates, MessageAuthentication Code (e.g., HMAC) gates, and so on.

In some aspects sensors, cameras, and other external hardware devicescan be arbitrarily assigned to a security zone.

In some aspects, the general term “cryptographic processing” relates tocryptographic operations such as encryption, decryption, digitalsigning, digital signature verification, secure hashing, key generation,and so on.

In another aspect, in general, a circuit for secure operation includes anumber of mutually exclusive circuit zones including a first circuitzone having a first level of security and a second circuit zone having asecond level of security less than the first level of security; and oneor more gate circuits each providing limited transfer of data betweenthe circuit zones, the gate circuits providing all data connectivitybetween the first circuit zone and the second circuit zone andstatically configured to prevent unmodified transfer of data from thefirst circuit zone to the second circuit zone.

Aspects may include one or more of the following.

Each gate circuit may implement a function defined by its circuit toprocess input data and provide output data via interfaces, each of theinterfaces located in a single corresponding circuit zone of theplurality of circuit zones. The function implemented by at least some ofthe gate circuits may include a cryptographic procedure utilizing acryptographic key. Each of the one or more gate circuits may follow adesign that enforces a security policy with the interfaces located inthe corresponding circuit zones to prevent unmodified transfers of databetween at least some of said circuit zones. The one or more gatecircuits may include one or more of an encryption gate circuit, acontrolled transfer gate circuit, a decryption gate circuit, a signinggate circuit, a secure hash function gate circuit, and a public keygeneration gate circuit. Each circuit zone of at least some of thecircuit zones may include a memory local to that circuit zone, whereinat least some of the gate circuits include an interface for accessingmemory locations in said memory.

The gate circuits may include an encryption gate circuit configured toaccept a key via a first interface in the first circuit zone, to acceptunencrypted data via a second interface, and to provide encrypted datavia third interface in the second circuit zone. The gate circuits mayinclude a decryption gate circuit configured to accept a key via a firstinterface in the first circuit zone, to accept encrypted data via asecond interface in the second circuit zone, and to provide decrypteddata via a third interface in the second circuit zone. The first circuitzone may include a key generation circuit for generation of a key valuewithout disclosure of said key value to the second circuit zone. Thedevice may be configured to use a key value provided to a gate circuitto encrypt data in at least one of the first circuit zone and the secondcircuit zone to provide corresponding encrypted data to the secondcircuit zone without disclosure of the key value into the second circuitzone.

The device may be configured to use a key value provided to a gatecircuit to decrypt data in the second circuit zone to providecorresponding decrypted data to the first circuit zone withoutdisclosure of the key value into the second circuit zone. The circuitmay include a key initialization circuit comprising at least one of anon-volatile storage in the first circuit zone, a Physical UnclonableFunction (PUF) in the first circuit zone, and port for passing a valuefrom outside the device to the first circuit zone. The device mayinclude a programmable processor located outside the first securityzone, wherein the circuit is configured to validate software forcontrolling the processor according to key values stored in the firstcircuit zone. The device may include a Field Programmable Gate Array(FPGA) configured according to configuration data to implement circuitzones and gate circuits. The device may include an Application SpecificIntegrated Circuit (ASIC).

In another aspect, in general, data stored on a non-transitory computerreadable medium includes configuration instructions for configuring acircuit having a plurality of mutually exclusive circuit zones includinga first circuit zone having a first level of security and a secondcircuit zone having a second level of security less than the first levelof security and one or more gate circuits each providing limitedtransfer of data between the circuit zones, the gate circuits providingall data connectivity between the first circuit zone and the secondcircuit zone and statically configured to prevent unmodified transfer ofdata from the first circuit zone to the second circuit zone.

Aspects may include one or more of the following features.

The configuration instructions may include hardware description language(HDL) instructions. The configuration instructions may includeinstructions for configuring a Field Programmable Gate Array (FPGA).

In another aspect, in general, a method for operating a device having afirst circuit zone having a first level of security and a second circuitzone, mutually exclusive from the first circuit zone and having a secondlevel of security less than the first level of security includesmaintaining data in the first circuit zone, providing first data in thefirst circuit zone to an interface in the first circuit zone to a firstgate circuit, the first gate circuit coupling the first circuit zone andthe second circuit zone, processing the first data in a first gatecircuit to produce second data, providing the second data from the firstgate circuit through a second interface in the second circuit zone,wherein the first gate circuit is configured by its circuit design toprocess the first data to produce the second data such that disclosureof the second data does not disclose of the first data.

Aspects may include one or more of the following features.

Processing the first data in the first gate circuit to produce seconddata may include forming the second data according to a cryptographicprocedure according to a key value in the first data. The cryptographicprocedure may include at least one of an encryption procedure, a signingprocedure, and a public key generation procedure. Processing the firstdata in the first gate circuit to produce second data may includeforming the second data as a secure hash of the first data.

The method may further include maintaining third data in the secondcircuit zone, providing the third data in the second circuit zone to athird interface in the second circuit zone to a second gate circuit, thesecond gate circuit coupling the first circuit zone and the secondcircuit zone, processing the third data in a second gate circuit toproduce fourth data, providing the fourth data from the second gatecircuit through a fourth interface in the first circuit zone, whereinthe second gate circuit is configured by its circuit design to processthe third data to produce the fourth data such that disclosure of thefourth data does not disclose the third data.

Processing the third data in the second gate circuit to produce fourthdata may include forming the fourth data according to a decryptionprocedure according to a key value in the first circuit zone.

In another aspect, in general, a method for operating a secure devicehaving a plurality of mutually exclusive circuit zones, including afirst circuit zone having a first level of security and a second circuitzone having a second level of security less than the first level ofsecurity, the method includes unpacking a key exchange package, theunpacking including receiving a key exchange package in the secondcircuit zone, the key exchange package including encrypted key data andprocessing the encrypted key data using a content key in the firstcircuit zone to generate decrypted key data and storing the decryptedkey data in the first circuit zone without disclosing the decrypted keydata into the second circuit zone.

Aspects may include one or more of the following features.

The key exchange package may include header data and the method furthercomprises processing the header data to generate the content key andstoring the content key in the first circuit zone without disclosing thecontent key into the second circuit zone. The key exchange package mayinclude encrypted key associated data and the method may further includeprocessing a data item in the first circuit zone with a non-invertiblefunction to generate a modified data item and storing the modified dataitem in the second circuit zone, and processing the encrypted keyassociated data using the modified data item to generate decrypted keyassociated data and storing the decrypted key associated data in thesecond circuit zone. The data item may include the content key.

The method may further include cryptographically processing data in thesecond circuit zone using the decrypted key data without disclosing thedecrypted key data into the second circuit zone. Cryptographicallyprocessing the data may include encrypting the data into the secondcircuit zone using the decrypted key data. Cryptographically processingthe data may include decrypting the data into the second circuit zoneusing the decrypted key data. The secure device may include a pluralityof gate circuits providing limited transfer of data between the circuitzones, the gate circuits providing all data connectivity between thefirst circuit zone and the second circuit zone and preventing unmodifiedtransfer of data from the first circuit zone to the second circuit zone.Processing the encrypted key data using the content key to generatedecrypted key data may include using a decryption gate circuit todecrypt the encrypted key data using the content key.

Processing the data item to generate a modified data item may includeusing a secure hash gate circuit to compute a secure hash of the dataitem. Processing the encrypted key associated data using the modifieddata item may include using a decryption circuit to decrypt theencrypted key associated data using the modified data item. At leastsome of the plurality gate circuits providing connectivity between thefirst circuit zone and the second circuit zone may store data in thefirst circuit zone. The method may further include performing acryptographic exchange with another secure device including using adecryption gate circuit to decrypt data received from the other devicein the second circuit zone using the decrypted key data withoutdisclosure of the decrypted key data into the second circuit zone.

The method may further include performing a cryptographic exchange withanother secure device including using an encryption gate circuit toencrypt data in the second circuit zone using the decrypted key datawithout disclosure of the decrypted key data into the second circuitzone. The secure device may include a root circuit zone having a thirdlevel of security greater than the first level of security and thesecond level of security, and processing the header data in the secondcircuit zone to generate the content key in the first circuit zoneincludes using a key agreement key in the root circuit zone. Decryptedkey associated data may include key metadata associated with thedecrypted key data.

In another aspect, in general, a method for operating one or more securedevices, each having a plurality of mutually exclusive circuit zones,including a first circuit zone having a first level of security and asecond circuit zone having a second level of security less than thefirst level of security, the method including processing, at a sendingdevice, key data using a content key to generate encrypted key data andstoring the encrypted key data in the second circuit zone withoutdisclosing the key data into the second circuit zone, packaging theencrypted key data into a key exchange package, and transmitting the keyexchange package to one or more receiving devices.

Aspects may include one or more of the following features.

The method may further include processing, at the sending device, a dataitem in the first circuit zone using a non-invertible function togenerate a modified data item and storing the modified data item in thesecond circuit zone without disclosing the data item into the secondcircuit zone processing, at the sending device, key associated datausing the modified data item to generate encrypted key associated dataand storing the encrypted key associated data in the second circuitzone, and packaging the encrypted key associated data into the keyexchange package.

The method may further include processing, at the sending device,private key data in the first circuit zone to generate header data andstoring the header data in the second circuit zone, and packaging theheader data into the key exchange package.

The one or more secure devices may include a plurality of gate circuitsproviding limited transfer of data between the circuit zones, the gatecircuits providing all data connectivity between the first circuit zoneand the second circuit zone and preventing unmodified transfer of datafrom the first circuit zone to the second circuit zone. Processing keydata using a content key to generate the encrypted key data may includeusing an encryption gate circuit to encrypt the key data using thecontent key. Processing the data item to generate a modified data itemmay include using a secure hash gate circuit to compute a secure hash ofthe data item. Processing the key associated data using the modifieddata item may include using an encryption circuit to encrypt the keyassociated data using the modified data item in the second circuit zone.At least some of the plurality gate circuits providing connectivitybetween the first circuit zone and the second circuit zone may storedata in the first circuit zone.

The method may further include receiving the key exchange package in asecond circuit zone of a receiving device, the key exchange packageincluding encrypted key data, processing, at the receiving device, theencrypted key data using a content key in the first circuit zone togenerate decrypted key data and storing the decrypted key data in thefirst circuit zone of the receiving device without disclosing thecontent key into the second circuit zone of the receiving device. Thekey exchange package may include header data and the method may furtherinclude processing, at the receiving device, the header data to generatea content key and storing the content key in the first circuit zone ofthe receiving device without disclosing the content key into the secondcircuit zone of the receiving device.

The key exchange package may include encrypted key associated data andthe method may further include processing, at the receiving device, adata item with a non-invertible function to generate a modified dataitem and storing the data item in the second circuit zone of thereceiving device without disclosing the data item into the secondcircuit zone of the receiving device; and processing, at the receivingdevice, the encrypted key associated data using the modified data itemto generate decrypted key associated data and storing the decrypted keyassociated data in the second circuit zone. The data item may includethe content key.

In another aspect, in general, a method for establishing group key dataamong a plurality of secure devices, each secure device having aplurality of mutually exclusive circuit zones, including a first circuitzone having a first level of security and a second circuit zone having asecond level of security less than the first level of security includingreceiving the key exchange package in a second circuit zone of each ofthe secure devices, the key exchange package including encrypted keydata, establishing a shared key data in the first circuit zone of eachof the secure devices including, for each of the secure devices,processing the encrypted key data using a content key to generatedecrypted key data and storing the decrypted key data in the firstcircuit zone of each of the secure device without disclosing the contentkey into the second circuit zone of the secure device, securelyexchanging messages between the secure devices, the messages beingprocessed by the shared key data.

Aspects may include one or more of the following features.

The method may further include distributing the key exchange packagefrom a secure computer server.

In another aspect, in general, a method for computer-implementedverification of security of a device includes accepting data comprisinga circuit description of the device, identifying using a computer aplurality of mutually independent circuit zones from the circuitdescription such that no data paths pass between said circuit zones,identifying a plurality of gate circuits providing data paths betweenthe circuit zones, the gate circuits being verified to limit unmodifiedtransfer of data between zones by their circuitry according to asecurity policy, and verifying that the security device complies withthe security policy according to whether all data paths between thecircuit zones are via the identified gate circuits according to thesecurity policy.

Aspects may include one or more of the following features.

The method may further include using a computer to verify that the gatecircuits limit unmodified transfer of data between zones by theircircuitry according to the security policy. Accepting the circuitdescription of the device may include accepting a specification of thecircuit zones of the device. The method may further include associatinga security index with each circuit zone, and wherein verifying that thesecurity device complies with the security policy comprises verifyingthat the security indices of interfaces between the gate circuits andthe circuit zones satisfy the security policy.

Other features and advantages of the invention are apparent from thefollowing description, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a hardware functional gate (HFG).

FIG. 2 is first encryption HFG.

FIG. 3 is a controlled transfer HFG.

FIG. 4 is a second encryption HFG.

FIG. 5 is a decryption HFG.

FIG. 6 is a digital signing HFG.

FIG. 7 is a secure hash function HFG.

FIG. 8 is a public key generation HFG.

FIG. 9 is a device including a number of HFGs.

FIG. 10 is a secure boot procedure.

FIG. 11 is an unlock procedure.

FIG. 12 is a provisioning procedure.

FIG. 13 is a first part of a keywrap generation procedure.

FIG. 14 is a second part of a keywrap generation procedure.

FIG. 15 is a first part of a key unwrap procedure.

FIG. 16 is a second part of a key unwrap procedure.

FIG. 17 is a key fob application of a key management and cryptographydevice.

FIG. 18 is a secure telephony application of a key management andcryptography device.

FIG. 19 is a secure processing application of a key management andcryptography device.

FIG. 20 is an unmanned aerial vehicle (UAV) group keying application ofa key management and cryptography device.

DESCRIPTION

The description below focuses on a security architecture for anintegrated device that incorporates cryptographic and key managementfunctions. In some implementations, the device is a standalone device(e.g., an integrated circuit), which may be integrated with host orperipheral devices, but it should be understood that the elementsdescribed below may be further integrated, for example, in a largermonolithic device. Also, devices that are structured according to thearchitecture may be implemented using a variety of technologies,including but not limited to field-programmable gate arrays (FPGAs) andapplication-specific integrated circuits (ASICs), and may include acombination of dedicated circuitry for specific functions as wellprogrammable embedded processing cores. Although useful functionalitymay be achieved using a single device, multiple devices each followingthe architecture may interact using the integrated cryptographic and keymanagement functions to achieve secure communication between ordistributed operation (e.g., identity management) of multiple devices,and devices following the architecture may interact with other securesystems that implement consistent security policies, but that do notnecessarily themselves follow the same architecture.

At a very general level, a device following the security architectureincludes multiple different security “zones.” Each zone is associatedwith a security level, such that for at least some pairs of zones, onezone may be designated to be less secure than the other. In someexamples, the security level for each zone is designated by non-negativeinteger index, which in this document as a matter of convention has alower value indicating a greater degree of security (i.e., securityindex 0 is the most secure level), and therefore the security order ofany two zones is determined by the security indices of the zones. Itshould be understood that in some implementations, the zones are onlypartially ordered according to their security levels and therefore therelative security level of certain pairs of zones is not defined.

Each security zone has associated circuitry that implements functionsand transformations of data within that zone. Although circuitryimplementing the functions within a circuit zones may be physicallyseparated in the layout of a particular device, logical separation ofthe zones is a primary factor that permits verification of the design ofa particular device as satisfying a security policy. In some examples,logical separation means that none of the circuitry related to datapaths of a given security zone is connected to the circuitry related todata paths of another security zone except rigorously verified gatecircuitry. Such logical separation may be verified, for example, usingautomated tools using a hardware description language (HDL)specification of the circuitry without necessarily making use of alayout of that circuitry on a device. Furthermore, various types ofcircuitry may be used to implement functions within any particular zone.For example, both dedicated logic circuitry and instruction (e.g.,software) based processors may be used within any particular zone, aslong as the inter-zone communication follows the security policy asdiscussed below.

In some implementations, circuitry implementing security zones may havefurther separations for security or other technical considerations. Forexample, different security zones may operate in different clock domainswith clock signals being generated independently in some zones fromother zones. Similarly, different security zones may operate indifferent power zones, thereby permitting power control within zones tocontrol energy consumption, temperature etc., and potentially to controlleakage of information between zones.

As an example of use of security zones, in some examples, information ata zone at security index 0 may include root cryptographic keys, which ifexposed could compromise security of numerous systems or communicationlinks. On the other hand, information at a security index 1 may includesession cryptographic keys, which if exposed may compromise security ofa single communication link, but may not lead to the degree of undesiredaccess that would result from exposure of a root key.

The security architecture is based on a security policy in whichexchange and use of data within a particular security level (e.g., in aparticular security zone) is relatively unrestricted, but exchange ofinformation between security levels is limited to enforce the securitypolicy. An example of a policy related to exchange of informationbetween security levels is that a data element at one security level maynot pass to a lower security (e.g., higher security index) zone unlessit is suitably hashed or encrypted with a key restricted to the highersecurity zone.

1 Hardware Functional Gates

In order to verify that a particular device follows the security policy,only a limited set of functional elements are permitted to have inputsand output that are in multiple different zones, and therefore can bethought of as “bridges” between zones or functionally “gating”communication and transfer of information between zones. These elementsare referred to as “Hardware Functional Gates” (HFG) or “gate circuits”below, without intending to limit any characteristic of such elements bythis nomenclature. A set of HFG that have been verified to satisfy adesired security policy can then be used to interconnect the otherwiseisolated circuits of the security zones. Verification of the HFG can useone or more of a variety of techniques including manual verification,use of formal verification procedures (e.g., proofs of correctness), andsimulation or enumeration of operation of the HFG. Verification that theoverall circuit satisfies the security policy is done by a staticanalysis of the circuitry of the device to ensure that theinterconnections between zones appropriately (i.e., according to thesecurity policies) use the HFGs, for example, using automated tools thatusing a hardware description language (HDL) specification of thecircuitry without necessarily making use of a layout of that circuitryon a device. The HFG can be considered to be a set of “building blocks”that can be used to implement complex security procedures or protocols,such that the overall implementations can be easily verified to adhereto the security policy by virtue of appropriate use of the HFGs.

Referring to FIG. 1, one example of an HFG is an encryption HFG 102bridging two security zones (i.e., Zone 1 104 and Zone 2 106). Theencryption HFG 102 has two input interfaces and one output interface.One input (K) is for a cryptographic key, and one input (D) is for adata item. In this example, both of the input interfaces are located inthe same security zone (i.e., Zone 1). The output (E) is for anencryption of the data item using the key. In this example, the outputinterface is located in security Zone 2 which has a lower level ofsecurity (and a higher security index) than the security zone of theinput interfaces (i.e., Zone 1). Furthermore, there is a controlinterface 109, which may be configured to accept a signal (e.g., “go”)that causes the HFG to perform its function and provides a signal (e.g.,“done”) indicating that the function has been completed.

The HFG has an associated security policy, which dictates allowablesecurity indexes to which the interfaces of the HFG may be coupled. IfZ(K) indicates the security index of the zone to which the key (K) inputis coupled, and similarly Z(D) and Z(E) indicates the zones of the datainput and encryption output, respectively, then a rule for use of theHFG may be that Z(E)Z(K) and Z(K)Z(D). This rule can be paraphrased asthe data D must be encrypted with a key (K) at the same or highersecurity level (same or lower security index), and the encryption of thedata E may be provided by the HFG to a zone at the same of lowersecurity level (higher security index) as the zone of the key input.

As introduced above, an overall circuit design is verified to adhere toa security policy if the circuit topology can be divided into separatezones (i.e., circuit subgraphs of possible data flow) with the onlylinkages for possible data flow between zones being restricted to HFGswhose interface circuits are coupled to particular zones consistent withtheir security policies.

In general, each security zone has distinct memory for use within thezone and for providing inputs to and storing outputs from the HFG. Insome examples, the memories of the zones include an addressable memoryblock of volatile memory. In some examples in which an HFG is designedto use the memories in the zones it interfaces with, the controlinterface to the HFG accepts a command that identifies the address(es)of the inputs and outputs. For instance, for the encryption HFGdiscussed above, rather than the control interface simply accepting a“go” and providing a “done” signal, the control interface may accept aninput address for each of the key and data inputs, and an output addressfor the encrypted output. Note that these addresses are interpreted inthe zones associated with the corresponding interfaces. At leastconceptually each zone can be considered to have its own address spacethat is only accessible from circuitry within that zone or frominterfaces assigned to that zone. In some cases, the control interfacemay accept parameters for the function (e.g., in addition to addresses).For example, a length of a data block to be encrypted may be provided tothe HFG (e.g., “encrypt a block of n bytes at address —addr1 using a keyat addr2, and save the result in a block of memory at address addr3”).In some examples, circuitry in a zone may be implemented using abus-based architecture in which each of the HFG and a memory block inthe zone, as well as other intra zone circuitry or processing units, areon a common zone-specific bus, which supports the read and write memoryoperations in the address space for that zone.

Referring to FIGS. 2-7, an example of a non-exhaustive set of HFGS thatcan be used to implement a variety of devices includes a firstembodiment of an encryption HFG, a controlled transfer HFG, a secondembodiment of an encryption HFG, a decryption HFG, a signing HFG, asecure hash HFG, and a public key generation HFG.

1.1 First Encryption HFG

Referring to FIG. 2, the first embodiment of the encryption HFG 202(which is similar to the encryption HFG 102 of FIG. 1) is shown bridginga first security zone (i.e., Zone 1) 204 and a second security zone(i.e., Zone 2) 206. The encryption HFG 202 is configured to encrypt adata item (D) stored in the first security zone 204 using an encryptionkey (K) stored in the first security zone 204 to produce an encrypteddata item E_(K) (D) which it stores in the second security zone 206.Different instances of such an encryption HFG may implement symmetricencryption (e.g., AES) or asymmetric encryption (e.g., RSA) procedures.The encryption HFG 202 has an associated security policy. The securitypolicy ensures that no secret information (e.g., the encryption key orplaintext D) is inadvertently transferred from the first security zone204 to the second security zone 206 through the encryption HFG 202. Thesecurity policy also ensures that the encryption HFG 202 does not allowdata from lower security zones to be arbitrarily placed into highersecurity zones and later (inadvertently or maliciously) used as a key toexfiltrate other keys or data from the higher security zones into thelower security zones. As is described above, the security policy for anyencryption HFG 202 is specified such that the data item D must beencrypted with a key (K) at the same or higher security level (same orlower security index), and the encryption of the data E_(K) (D) may beprovided by the HFG to a zone at the same or lower security level(higher security index) as the zone of the key input. As was notedabove, this security policy can be concisely stated as: Z(E)≧Z(K) and Z(K)≧Z(D). The first embodiment of the encryption HFG 202 complies withthe security policy since encryption of the data E is provided by theHFG to a zone (i.e., Zone 2) with a lower security level (highersecurity index) than the zone (i.e., Zone 1) of the key input and thedata item D is encrypted with an encryption key K at a zone (i.e.,Zone 1) having the same security level (the same security index) as thezone (i.e, Zone 1) associated with the data item (i.e., Z(E)>Z(K) andZ(K)=Z(D)).

To receive input data, the encryption HFG 202 includes a data item inputinterface 203 and an encryption key input interface 205 both located inthe first security zone 204. To provide output data, the encryption HFG202 includes an encrypted data item output interface 207 located in thesecond security zone 206. The data item input interface 203 and theencryption key input interface 205 are connected to a Zone 1 memory 212via a Zone 1 bus 208. The encrypted data item output interface 207 isconnected to a Zone 2 memory 214 via a Zone 2 bus 210.

In some examples, the encryption HFG 202 includes a control interface209 which receives commands from a controller (not shown). In oneexemplary operation of the encryption HFG 202, the control interface 209receives a command from the controller instructing the encryption HFG202 to encrypt a data item (D) at a first address, addr1, in the Zone 1memory 212 using an encryption key (K) at a second address, addr2, inthe Zone 1 memory 212 and to store the resulting encrypted data item(E_(K) (D)) at a third address, addr3, in the Zone 2 memory 214.

The command causes the encryption HFG 202 to read the data item fromaddr1 of the Zone 1 memory 212 and the encryption key from addr2 of theZone 1 memory 212 via the Zone 1 bus 108. In some examples, theencryption HFG 202 reads the data item and the encryption key from theZone 1 memory 212 in parallel. In other examples, the data item and theencryption key are sequentially read from the Zone 1 memory 212 andstored (e.g. latched) by the encryption HFG 202. Once the encryption HFG202 receives the data item and the encryption key at their respectiveinput interfaces 203, 205, the encryption HFG 202 applies an encryptionalgorithm (e.g., the Advanced Encryption Standard (AES) encryptionalgorithm) to encrypt the data item using the encryption key. Theencryption HFG 202 stores the resulting encrypted data item at addr3 ofthe Zone 2 memory 214 via the Zone 2 bus 210.

Since the encryption HFG 202 conforms to the security policy describedabove and includes verified hardware which does not allow leakage ofprotected information between zones, it is impossible or exceedinglydifficult for an attacker to determine the encryption key or otherprotected information by probing the encryption HFG 202. It is alsoimpossible or exceedingly difficult for an attacker to use theencryption HFG 202 to arbitrarily place data from lower security zonesinto higher security zones such that the data can later (inadvertentlyor maliciously) be used as a key to exfiltrate other keys or data fromthe higher security zones into the lower security zones.

1.2 Controlled Transfer HFG

Referring to FIG. 3, the controlled transfer HFG 316 (sometimes referredto as a “controlled transfer gate”) is shown bridging a first securityzone (i.e., Zone 1) 304 and a second security zone (i.e., Zone 2) 306,the first security zone 304 having a higher level of security than thesecond security zone 306. The controlled transfer HFG 316 is configuredto retrieve a data item (D) from the second security zone 306 and tostore the data item, unmodified, in the first security zone 304. Thecontrolled transfer HFG 316 has an associated security policy. Thesecurity policy ensures that no secret information (e.g., the privatekey) is inadvertently transferred from the first security zone 804 tothe second security zone 806 through the controlled transfer HFG 316.The security policy for the controlled transfer HFG 316 is specifiedsuch that the security level of the zone from which the data item isread must be lower than the security level of the zone from which thedata item is written out. The security policy for the controlledtransfer HFG 316 can be concisely stated as: Z(D_(Out))>Z(D_(in)).

To receive the data item as input, the controlled transfer HFG 316includes a data item input interface 318 located in the second securityzone 306 and connected to a Zone 2 memory 314 via a Zone 2 bus 310. Toprovide the data item as output, the controlled transfer HFG 316includes a data item output interface 320 located in the first securityzone 304 and connected to a Zone 1 memory 312 via a Zone 1 bus 308.

In some examples, the controlled transfer HFG 316 includes a controlinterface 309 which receives commands from a controller (not shown). Inone exemplary operation of the controlled transfer HFG 316, the controlinterface 309 receives a command from the controller instructing thecontrolled transfer HFG 316 to retrieve a data item (D) from a firstaddress, addr1, in the Zone 2 memory 314 and transfer the data item to asecond address, addr2, in the Zone 1 memory 312. The command causes thecontrolled transfer HFG 316 to read the data item from addr1 of the Zone2 memory 314 via the Zone 2 bus 310. Once the controlled transfer HFG316 receives the data item, the controlled transfer HFG 316 writes thedata item, without modification, to addr2 of the Zone 1 memory 312 viathe Zone 1 bus 308.

Since the controlled transfer HFG 316 conforms to the security policydescribed above and includes verified hardware which does not allowleakage of protected information between zones, it is impossible orexceedingly difficult for an attacker to access information in Zone 1304 by probing the controlled transfer HFG 316.

In some examples, the controlled transfer HFG 316 includes logic whichanalyzes the data item (D) to determine whether it meets certainconditions (e.g., length, format, or rate conditions). If it isdetermined that the data item does not meet the conditions, then thecontrolled transfer HFG 316 does not transfer the data item into thefirst security zone.

In other examples, the controlled transfer HFG 316 includes logic whichallows only a single data item to be transferred through the HFG. Forexample, the HFG may maintain a bit representing whether a data item hasyet been transferred though the HFG. Before any data item has beentransferred through the HFG, the value of the bit is set to 0. When arequest to transfer a data item is received at the controlled transferHFG, the value of the bit is read. If the value of the bit is 0, datatransfer is permitted. Upon transferring a data item through thecontrolled transfer HFG, the value of the bit is set to 1. If the valueof the bit is 1, data transfer is not permitted. Thus, after a singledata item is transferred through the controlled transfer HFG, anysubsequent attempts to transfer data through the controlled transfer HFGare not permitted due to the value of the bit being set to 1. In thisway, the controlled transfer HFG logic prevents data from lower securityzones from being arbitrarily placed into higher security zones and later(inadvertently or maliciously) be used as a key to exfiltrate other keysor data from the higher security zones into the lower security zones.

In some examples, the controlled transfer HFG is used to place the dataitem (D) into a designated staging area where other HFGs have access tothe data item. In some examples, the designated staging areas includememory which is separate from the memory in which keys are stored.

1.3 Second Encryption HFG

Referring to FIG. 4 a second embodiment of an encryption HFG 422 isshown bridging a first security zone (i.e., Zone 1) 404 and a secondsecurity zone (i.e., Zone 2) 406. The encryption HFG 422 is configuredto encrypt a data item (D) stored in the second security zone 406 usingan encryption key (K) stored in the first security zone 404 to producean encrypted data item E_(K) (D) which it stores in the second securityzone 406. To ensure that no secret information (e.g., the private key)is inadvertently transferred from the first security zone 404 to thesecond security zone 406 through the encryption HFG 422, encryption HFG422 complies with the general encryption HFG security policy describedabove. In particular, the encryption HFG 422 complies with the generalencryption HFG security policy since the encryption of the data itemE_(K) (D) is provided by the encryption HFG 422 to a zone with a lowersecurity level (higher security index) than the zone of the key inputand the data item D is encrypted with an encryption key K at a zonehaving a higher security level (a lower security index) than the zoneassociated with the data item (i.e., Z(E)>Z(K) and Z(K)<Z(D)).

To receive input data, the encryption HFG 422 includes a data item inputinterface 403 located in the second security zone 406 and an encryptionkey input interface 405 located in the first security zone 404. Toprovide output data, the encryption HFG 422 includes an encrypted dataitem output interface 407 located in the second security zone 406. Thedata item input interface 403 and the encrypted data item outputinterface 407 are connected to a Zone 2 memory 414 via a Zone 2 bus 408.The encryption key input interface 405 is connected to a Zone 1 memory412 via a Zone 1 bus 408.

Internally, an example of the second embodiment of the encryption HFG422 includes the first embodiment of the encryption HFG 402 of FIG. 2and the controlled transfer HFG 416 of FIG. 3. The controlled transferHFG 416 is used to transfer the data item D from Zone 2 406 into Zone 1404 for encryption using the first embodiment of the encryption HFG 402.Specifically, the data item input interface 403 of the second embodimentof the encryption HFG 422 is connected to the data item input 418 of thecontrolled transfer HFG 416 in Zone 2. The data item output interface420 of the controlled transfer HFG 416 is connected to the data iteminput interface 403′ of the first embodiment of the encryption HFG 402.The encryption key input interface 405 of the second embodiment of theencryption HFG 422 is connected to the encryption key input interface405′ of the first embodiment of the encryption HFG 402. The encrypteddata item output interface 407′ of the first embodiment of theencryption HFG 402 is connected to encrypted data output interface 407of the second embodiment of the encryption HFG 422. Of course, not allimplementations make use of such an internal arrangement, for example,using an optimized circuit that achieves the same functionality and dataprotection.

In some examples, the second embodiment of the encryption HFG 422includes a control interface 409 which receives commands from acontroller (not shown) and provides the commands to a control interface409′ of the first embodiment of the encryption HFG 402 and to a controlinterface 411 of the controlled transfer HFG 416. In one exemplaryoperation of the encryption HFG 422, the control interface 409 receivesa command from the controller instructing the encryption HFG 422 toencrypt a data item (D) at a first address, addr1, in the Zone 2 memory414 using an encryption key (K) at a second address, addr2, in the Zone1 memory 412 and to store the resulting encrypted data item (E_(K) (D))at a third address, addr3, in the Zone 2 memory 214.

The command causes the controlled transfer HFG 416 to read the data item(D) from addr1 of the Zone 2 memory 414 via the Zone 2 bus 410. Once thecontrolled transfer HFG 416 receives the data item, the controlledtransfer HFG 416 provides the data item, without modification, to thedata item input interface 403′ of the first embodiment of the encryptionHFG 402. The command also causes the first embodiment of the encryptionHFG 402 to read the encryption key (K) from addr2 of the Zone 1 memory412 via the Zone 1 bus 408. Once the first embodiment of the encryptionHFG 402 receives the data item and the encryption key at theirrespective input interfaces 403′, 405′ the first embodiment of theencryption HFG 402 applies an encryption algorithm to encrypt the dataitem using the encryption key. The first embodiment of the encryptionHFG 202 stores the resulting encrypted data item E_(K) (D) at addr3 ofthe Zone 2 memory via the Zone 2 bus 410.

Since the second embodiment of the encryption HFG 422 and its componentparts (i.e., the first embodiment of the encryption HFG 402 and thecontrolled transfer HFG 416) all conform to the encryption securitypolicy described above and include verified hardware which does notallow leakage of encryption key information between zones, it isimpossible or exceedingly difficult for an attacker to determine theencryption key or other protected information by probing the secondembodiment of the encryption HFG 422. It is also impossible orexceedingly difficult for an attacker to use the encryption HFG 422 toarbitrarily place data from lower security zones into higher securityzones such that the data can later (inadvertently or maliciously) beused as a key to exfiltrate other keys or data from the higher securityzones into the lower security zones.

1.4 Decryption HFG

Referring to FIG. 5, the decryption HFG 524 is shown bridging a firstsecurity zone (i.e., Zone 1) 504 and a second security zone (i.e., Zone2) 506, the first security zone 504 having a higher level of securitythan the second security zone 506. The decryption HFG 524 is configuredto decrypt an encrypted data item (E_(K) (D)) stored in the secondsecurity zone 506 using an encryption key (K) stored in the firstsecurity zone 504 to produce an unencrypted data item (D) which itstores in the first security zone 504.

The decryption HFG 524 has an associated security policy. The securitypolicy ensures that no secret information (e.g., the private key) isinadvertently transferred from the first security zone 504 to the secondsecurity zone 506 through the decryption HFG 524. The security policyalso ensures that the decryption HFG 524 does not allow data from lowersecurity zones to be arbitrarily placed into higher security zones andlater (inadvertently or maliciously) used as a key to exfiltrate otherkeys or data from the higher security zones into the lower securityzones. The security policy for the decryption HFT 524 is specified suchthat an encrypted data item (E_(K) (D)) must be decrypted with anencryption key (K) at the same or higher security level (same or lowersecurity index) and the decrypted data item (D) must be provided to azone at the same security level (security index) as the zone of theencryption key. This security policy can be concisely stated as:Z(E)≧Z(K) and Z(K)=Z(D)).

To receive input data, the decryption HFG 524 includes an encrypted dataitem input interface 526 located in the second security zone 506 andconnected to a Zone 2 memory 514 via a Zone 2 bus 510 and an encryptionkey input 505 located in the first security zone 504 and connected to aZone 1 memory 512 via a Zone 1 bus 508. To provide a decrypted data itemoutput, the decryption HFG 524 includes a data item output interface 528located in the first security zone 504 and coupled to the Zone 1 memory514 via the Zone 1 bus 508.

In some examples, the decryption HFG 524 includes a control interface509 which receives commands from a controller (not shown). In oneexemplary operation of the decryption HFG 52, the control interface 509receives a command from the controller instructing the decryption HFG524 to decrypt an encrypted data item (E_(K) (D)) at a first address,addr1, in the Zone 2 memory 514 using an encryption key (K) at a secondaddress, addr2, in the Zone 1 memory 512 and to store the resultingdecrypted data item (D) at a third address, addr3, in the Zone 1 memory512.

The command causes the decryption HFG 524 to read the encrypted dataitem from addr1 of the Zone 2 memory 514 via the Zone 2 bus 510 and toread the encryption key from addr2 in the Zone 1 memory 512 via the Zone1 bus 508. Once the decryption HFG 524 receives the encrypted data itemand the encryption key at their respective input interfaces 526, 505,the decryption HFG 524 applies a decryption algorithm (e.g., the AESdecryption algorithm) to decrypt the encrypted data item using theencryption key. The decryption HFG 524 stores the resulting decrypteddata item at addr3 of the Zone 1 memory 514 via the Zone 1 bus 508.

Since the decryption HFG 524 conforms to the security policy describedabove and includes verified hardware which does not allow leakage of theencryption key or other protected information between zones, it isimpossible or exceedingly difficult for an attacker to determine theencryption key or other protected information by probing the decryptionHFG 524. It is also impossible or exceedingly difficult for an attackerto use the decryption HFG 524 to arbitrarily place data from lowersecurity zones into higher security zones such that the data can later(inadvertently or maliciously) be used as a key to exfiltrate other keysor data from the higher security zones into the lower security zones.

Note that together, an encryption, for example HFG 202 (see FIG. 2), anda decryption HFG 524 (see FIG. 5) provide a means to export a data itemD from a secure zone (i.e., zone 1) as an encrypted (e.g., opaque) dataitem E_(K) (D), which may be stored in a non-secure location, and thenlater imported back to the same zone, or any other zone (e.g., a zone 1at another device), which holds the matching key K used to decrypt thedata item.

1.5 Signing HFG

Referring to FIG. 6, the signing HFG 634 is shown bridging threesecurity zones: a first security zone (i.e., Zone 0) 633, a secondsecurity zone (i.e., Zone 1) 604, and a third security zone (i.e., Zone2) 606. The first security zone 633 has a higher level of security thanthe second security zone 604 which in turn has a higher security levelthan the third security zone 606.

The signing HFG 634 is configured to digitally sign a data item (D)stored in the second security zone 604 using a cryptographic key (K)stored in the first security zone 633 and a random number (R) to producea signature of the data item (S(D)) which it stores in the thirdsecurity zone 606. When a device including the signing HFG 634 sends thesigned data item to a receiver, the receiver can verify the signature toensure that the data is authentic and from the device.

The signing HFG 634 has an associated security policy. The securitypolicy ensures that no secret information (e.g., the private key) isinadvertently transferred from the first security zone 633 to the secondsecurity zone 604 or third zone 606 through the signing HFG 634. Thesecurity policy also ensures that the signing HFG 634 does not allowdata from lower security zones to be arbitrarily placed into highersecurity zones and later (inadvertently or maliciously) used as a key toexfiltrate other keys or data from the higher security zones into thelower security zones. The security policy for the signing HFG 634 isspecified such that a data item (D) must be signed using a key (K) fromthe same or higher security level and the signature of the data item(S(D)) may be provided to a zone at the same or lesser security level asthe zone of the encryption key. This security policy can be conciselystated as: Z(S)≧Z(K) and Z(K)≧Z(D)

To receive input data, the signing HFG 634 includes a cryptographic keyinput interface 605 located in the first security zone 633, a randomvalue interface 607 located in the first security zone 633, and a dataitem input interface 603 located in the second security zone 604. Toprovide output data, the signing HFG 634 includes a signed data outputinterface 628 located in the third security zone 606. The cryptographickey input interface 605 is connected to a Zone 0 memory 630 via a Zone 0bus 632. The data item interface 603 and the random value interface 607are connected to a Zone 1 memory 612 via a Zone 1 bus 608. The signeddata output interface 628 is connected to a Zone 2 memory 614 via a Zone2 bus 610.

In some examples, the signing HFG 634 includes a control interface 609which receives commands from a controller (not shown). In one exemplaryoperation of the signing HFG 634, the control interface 609 receives acommand from the controller instructing the signing HFG 634 to sign adata item (D) at a first address, addr1, in the Zone 1 memory 612 usinga random value (R) at a fourth address, addr4, in Zone 1 memory and asigning key (K) at a second address, addr2, in the Zone 0 memory 630 andto store the resulting signed data item (S(D)) at a third address,addr3, in the Zone 2 memory 214.

The command causes the signing HFG 634 to read the data item from addr1of the Zone 1 memory 612 via the Zone 1 bus 608, to read the randomvalue from addr4 of the Zone 1 memory 612 via the Zone 1 bus 608, and toread the signing key from addr2 of the Zone 0 memory 630 via the Zone 0bus 632. Once the signing HFG 202 receives the data item, the randomvalue, and the cryptographic key at their respective input interfaces603, 605, the signing HFG 634 applies a digital signing algorithm (e.g.,the Elliptic Curve Digital Signing Algorithm (ECDSA)) to sign the dataitem using the signing key. The signing HFG 634 stores the resultingsigned data item S(D) at addr3 of the Zone 2 memory 614 via the Zone 2bus 610.

Since the signing HFG 634 conforms to the security policy describedabove (i.e., Z(S)>Z(K) and Z(K)<Z(D)) and includes verified hardwarewhich does not allow leakage of encryption key information betweenzones, it is impossible or exceedingly difficult for an attacker todetermine the cryptographic key or other protected information byprobing the signing HFG 634. It is also impossible or exceedinglydifficult for an attacker to use the signing HFG 634 to arbitrarilyplace data from lower security zones into higher security zones suchthat the data can later (inadvertently or maliciously) be used as a keyto exfiltrate other keys or data from the higher security zones into thelower security zones.

Similar to the signing HFG 634, another HFG that is not illustratedperforms a signature verification, for example accepting a purportedsignature S rather than providing it as with the signing HFG, andproviding a control signal to the same zone as the signature indicatingwhether the signature is valid based on the data D and key K at the sameor higher security zones.

1.6 Secure Hash HFG

Referring to FIG. 7, the secure hash (SHA) HFG 736 is shown bridging afirst security zone (i.e., Zone 1) 704 and a second security zone (i.e.,Zone 2) 706, the first security zone 704 having a higher level ofsecurity than the second security zone 706. The secure hash HFG 736 isconfigured to securely hash a data item (D) stored in the first securityzone 704 and store the secure hash of the data item (H) in the secondsecurity zone 706.

The secure hash HFG 736 has an associated security policy. The securitypolicy ensures that no protected information is inadvertentlytransferred from the first security zone 704 to the second security zone706 through the secure hash HFG 736. The security policy also ensuresthat the secure hash HFG 736 does not allow data from lower securityzones to be arbitrarily placed into higher security zones and later(inadvertently or maliciously) used as a key to exfiltrate other keys ordata from the higher security zones into the lower security zones. Thesecurity policy is specified such that the secure hash of the data itemH may be provided to a security zone with the same or lower securitylevel (higher security index) as the zone of the data item. Thissecurity policy can be concisely stated as: Z(H)≧Z(D).

To receive the data item as input, the secure hash HFG 736 includes adata item input interface 703 located in the first security zone 704 andconnected to a Zone 1 memory 712 via a Zone 1 bus 710. To provide thesecure hash of the data item as output, the secure hash HFG 736 includesa secure hash output interface 738 located in the second security zone706 and connected to a Zone 2 memory 714 via a Zone 2 bus 710.

In some examples, the secure hash HFG 736 includes a control interface709 which receives commands from a controller (not shown). In oneexemplary operation of the secure hash HFG 736, the control interface709 receives a command from the controller instructing the secure hashHFG 736 to perform a secure hash operation on a data item (D) at a firstaddress, addr1, in the Zone 1 memory 712 and to store the resultingsecurely hashed data item (H) in a second address, addr2, in the Zone 2memory 714.

The command causes the secure hash HFG 736 to read the data item fromaddr1 of the Zone 1 memory 712 via the Zone 1 bus 708. Once the securehash HFG 736 receives the data item at its data item input interface703, the secure hash HFG 736 applies a secure hash function to the dataitem, resulting in a secure hash of the data item. The secure hash HFG736 stores the resulting secure hash of the data item at addr2 of theZone 2 memory 714 via the Zone 2 bus 710.

Since the secure hash HFG 736 conforms to the security policy describedabove (i.e., Z(H)>Z(D)) and includes verified hardware which does notallow leakage of information (e.g., the data item) between zones, it isimpossible or exceedingly difficult for an attacker to determine thedata item or other protected information by probing the secure hash HFG736. It is also impossible or exceedingly difficult for an attacker touse the secure hash HFG 736 to arbitrarily place data from lowersecurity zones into higher security zones such that the data can later(inadvertently or maliciously) be used as a key to exfiltrate other keysor data from the higher security zones into the lower security zones.

1.7 Public Key Generation HFG

Referring to FIG. 8, the public key generation HFG 840 is shown bridginga first security zone (i.e., Zone 1) 804 and a second security zone(i.e., Zone 2) 806, the first security zone 804 having a higher level ofsecurity than the second security zone 806. The public key generationHFG 840 is configured to retrieve a private key (K_(Pr)) from the firstsecurity zone 804 and to use the private key to generate a correspondingpublic key (K_(Pu)) which it stores in the second security zone 806.

The public key generation HFG 840 has an associated security policy. Thesecurity policy ensures that no secret information (e.g., the privatekey) is inadvertently transferred from the first security zone 804 tothe second security zone 806 through the public key generation HFG 840.The security policy also ensures that the public key HFG 840 does notallow data from lower security zones to be arbitrarily placed intohigher security zones and later (inadvertently or maliciously) used as akey to exfiltrate other keys or data from the higher security zones intothe lower security zones. The security policy for the public keygeneration HFG 840 is specified such that the public key generated bythe public key generation HFG 840 may be provided by the HFG to a zoneat the same or lower security level (higher security index) as theprivate key. The security policy for the public key generation HFG 840can be concisely stated as: Z(K_(Pu))≧Z (K_(Pr))

To receive the private key as input, the public key generation HFG 840includes a private key input interface 842 located in the first securityzone 804 and connected to a Zone 1 memory 812 via a Zone 1 bus 808. Toprovide the generated public key as output, the public key generationHFG 840 includes a public key output interface 844 located in the secondzone 806 and connected to a Zone 2 memory 814 via a Zone 2 bus 810.

In some examples, the public key generation HFG 840 includes a controlinterface 809 which receives commands from a controller (not shown). Inone exemplary operation of the public key generation HFG 840, thecontrol interface 890 receives a command from the controller instructingthe public key generation HFG 840 to generate a public key from aprivate key at a first address, addr1, in the Zone 1 memory 812 and tostore the generated public key at a second address, addr2, in the Zone 2memory 814.

The command causes the public key generation HFG 840 to read the privatekey (K_(Pr)) from addr1 of the Zone 1 memory 812 via the Zone 1 bus 808.Once the public key generation HFG 840 receives the private key at itsprivate key input interface 842, the public key generation HFG 840 usesthe private key to generate a public key (e.g., an ephemeral publickey). The public key generation HFG 840 stores the resulting public keyat addr2 of the Zone 2 memory 814 via the Zone 2 bus 810.

Since the public key generation HFG 840 conforms to the security policydescribed above (i.e., Z(K_(Pu))>Z(K_(Pr))) and includes verifiedhardware which does not allow leakage of information (e.g., the privatekey) between zones, it is impossible or exceedingly difficult for anattacker to determine the private key or other protected information byprobing the public key generation HFG 634. It is also impossible orexceedingly difficult for an attacker to use the public key generationHFG 840 to arbitrarily place data from lower security zones into highersecurity zones such that the data can later (inadvertently ormaliciously) be used as a key to exfiltrate other keys or data from thehigher security zones into the lower security zones.

While the set of HFGs described above may be sufficient forimplementation of some devices, other devices may include additionaltypes of HFGs for securely communicating between security zones.

In the examples described above, HFGs were shown bridging either two orthree security zones. However, it is noted that a given HFG can bridge agreater or fewer number of security zones as long as its security policyis observed.

1.8 Other Circuit Elements

The library of HFG defined to implement a security policy is optionallyextended to include elements that may be used exclusively within onezone. For example, a secure hash element does not necessarily have to beused to bridge zones, and may be used exclusively within one zone. Also,some elements, such as a true random number generator or a pseudo-randomnumber generator may be included in the library only for use within asingle zone.

In the discussion above, and below, HFGs instances may be shown asdistinct even if they implement the same function and have theinterfaces in the same zones. In such cases, these instances may beimplemented in the device as a single shared circuit element, forexample, multiplexing and demultiplexing different inputs and outputsfor different operations. Note however, that such multiplexing cannot beimplemented in a manner that would violated the policy regarding passingdata between zones.

1.9 Logical Functional Gates

In some implementations, in addition to the HFG, which enforce thesecurity policy by virtue of the functions that are possible toimplement according to the circuitry, additional gate elements may beverified to provide logical security in that data security may beenforced if the element is suitably controlled (e.g., the logicimplemented for the controlled transfer HFG described above). Suchelements are referred to as “logical functional gates”. Note thatalthough using such logical gates between zones may provide a degree ofsecurity assuming that the logical control of the elements is notcompromised for example by errors in implementation, such logical gatesare not used between zones where a strict security policy is to beenforced and verified by the static hardware analysis.

2 Key Management and Cryptography Device

Referring to FIG. 9, one example of a key management and cryptographydevice 900 utilizes the HFGs described above to manage cryptographickeys and perform cryptographic tasks (e.g., create various keys forvarious purposes, associate meta-data with the keys, use cryptographicfunctions to protect application data using the keys, and so on). Thedevice can also protect keys (and meta-data) at rest and securely wrapkeys (with their meta-data) to other compatible devices. In someexamples, such a device is used as part of a larger system whichrequires key management and cryptography services.

The example device 900 includes four security zones each associated witha security index. In general, a lower the security index denotes ahigher the level of security. That is, Zone 0 (i.e., the security zoneassociated with security index 0) has the highest level of security andZone 3 (i.e., the security zone associated with security index 3) hasthe lowest level of security. With the exception an initial “unlocking”procedure (described below), all transfer of data between zones (e.g.,from zones with lower security indices to zones with higher securityindices) must be performed through HFGs.

In general, Zones 0-3 each includes a memory and a bus. That is, Zone 0933 includes a Zone 0 memory 930 and a Zone 0 bus 932, Zone 1 904includes a Zone 1 memory 912 and a Zone 1 bus 908, and Zone 2 includes aZone 2 memory 914 and a Zone 2 bus 910. HFGs and other hardware moduleswith interfaces in a given zone can access the zone's memory via thezone's bus. The bus may also communicate control information to and fromHFGs and other hardware modules. Such control information may originate,for example, from a microcontroller (e.g., a Tensilica processor in Zone3) or from a zone specific controller. In general, for the sake ofsimplicity, control information paths are not illustrated in thefigures.

Zone 0 has the highest level of security and is used to store criticaldata such as root keys and digital signing keys. To maintain the highestlevel of security, the number of HFGs bridging the boundary of Zone 0 isminimal. Zone 1 is somewhat less secure than Zone 0. Zone 1 has agreater number of HFGs bridging its boundaries, some of which haveinterfaces in less secure Zones 2 and 3. In general, Zone 1 is used toperform the majority of functions related to provisioning the device,unlocking the device, session key generation, generation and unwrappingof keywrap data, and so forth. Zone 2 generally acts as an interface andstaging area between custom code running in Zone 3 and the more securezones. For example, Zone 2 may store a keywrap in the Zone 2 memory 914such that Zones 0 and 1 can access the keywrap.

As is noted above, Zone 3 is configurable for executing custom,application specific code (e.g., C language software) which providesdata such as keywraps to Zone 2 and sends commands to Zone 2 whichultimately trigger key management and cryptography operations in Zones 0and 1. In some examples, data is communicated between Zone 2 and Zone 3via an input FIFO queue 961 and an output FIFO queue 963. Note that inthis implementation, Zone 3 and Zone 2 are not at different securitylevels because data can flow in a logically controlled manner from Zone2 to Zone 3 via the FIFO queue 961 without “scrambling”. However, thelogical rather than hardware separation of Zone 2 from Zone 3 doesprovide a degree of security in that there is not unfettered access tothe Zone 2 memory from Zone 3. In some examples, Zone 3 is alsoconfigured to receive unencrypted “red” data and apply an encryptionalgorithm, using an encryption key from Zone 1, to the unencrypted datato generate encrypted “black” output data.

2.1 Device HFGs and Hardware Modules

The device 900 includes a number of HFGs, for example as presentedabove, and a number of zone specific hardware modules (i.e., hardwaremodules which do not bridge boundaries between zones). The hardwaremodules and HFGs are briefly described below and detailed examples oftheir usage are presented in later sections.

An Elliptic Curve Diffie-Hellman (ECDH) HFG 954 for generatingcryptographic keys bridges Zones 0, 1, and 2. In Zone 0, the ECDH HFG954 is connected to the Zone 0 bus 932 such that it can receive data(e.g., key agreement keys) from the Zone 0 memory 930. In Zone 1, theECDH HFG 954 is connected to the Zone 1 bus 908 such that it can receivedata (e.g., key encryption keys) from and store data (e.g., theresulting symmetric key) in the Zone 1 memory 912. In Zone 2, the ECDGHFG 954 is connected to the Zone 2 bus 910 such that it can receive data(e.g., Public EDCH keys) from the Zone 2 memory 914.

An Elliptic Curve Digital Signature Algorithm (ECDSA) HFG 956 fordigitally signing data also bridges Zones 0, 1, and 2. In Zone 0, theECDSA HFG 956 is connected to the Zone 0 bus 932 such that it canreceive data (e.g., a signing key) from the Zone 0 memory 930. In Zone1, the ECDSA HFG 956 is connected to the Zone 1 bus 908 such that it canreceive data (e.g., a random value) from the Zone 1 memory 912. In Zone2, the ECDSA HFG 956 is connected to the Zone 2 bus 910 such that it canreceive data (e.g., a hash of a key update block) from and storesignature data (e.g., a signed hash of a key update block) in the Zone 2memory 914.

A controlled transfer HFG 958 for writing data into the Zone 0 memory930 bridges Zones 0 and 1. In Zone 0, the controlled transfer HFG 958 isconnected to the Zone 0 bus 932 such that it can store data (e.g., rootkeys, digital signing keys) in the Zone 0 memory 930. In Zone 1, thecontrolled transfer HFG 958 is connected to the Zone 1 bus 908 such thatit can read data (e.g., root keys) from the Zone 1 memory 912. In someexamples, the controlled transfer HFG 958 is only functional duringunlocking of the device 900 and is disabled during other operatingphases of the device 900. Disabling the controlled transfer HFG 958prevents unwanted or unnecessary writing of data to the Zone 0 memory930.

An AES engine HFG 948 for encrypting plaintext data 950 to generateencrypted data 952 bridges Zones 1 and 3. In Zone 1, the AES encryptorHFG 948 is connected to the Zone 1 bus 908 such that it can receive anencryption key (e.g., a session key) from the Zone 1 memory 912. In Zone3, the AES encryptor HFG 948 has an input interface for receivingunencrypted plaintext data (e.g., from a “red” security zone) and anoutput interface for providing encrypted output data (e.g., to a “black”security zone) 952.

A secure hash function (SHA) HFG 960 for generating a secure hash valuefrom a data item bridges Zones 1 and 2. In Zone 1, the first SHA HFG 960is connected to the Zone 1 bus 908 such that it can receive a data item(e.g., a content encryption key) from the Zone 1 memory 912. In Zone 2,the SHA HFG 960 is connected to the Zone 2 bus 910 such that it canreceive data (e.g., a nonce) from the Zone 2 memory 914 and provide asecure has of the data item (e.g., a secure hash of a content encryptionkey) to the Zone 2 memory 914.

A public key generation (PubKey) HFG 962 for generating a public keyfrom a private key bridges Zones 1 and 2. In Zone 1, the PubKey HFG 962is connected to the Zone 1 bus 908 such that it can receive a privatekey (e.g., an Elliptic Curve Diffie-Hellman private key) from the Zone 1memory 912. In Zone 2, the PubKey HFG 962 is connected to the Zone 2 bus910 such that it can provide a public key (e.g., an Elliptic CurveDiffie-Hellman public key corresponding to the private key) to the Zone2 memory 914.

An AES KeyWrap decryption (AES KW (D)) HFG 964 bridges Zones 1 and 2 andis configured to decrypt an encrypted data item (e.g., an encryptedcontent encryption key) from the Zone 2 memory 914 using an encryptionkey from the Zone 1 memory 912 and to store the decrypted data item inthe Zone 1 memory 912. In Zone 1, the AES KW (D) HFG 964 is connected tothe Zone 1 bus 908 such that it can receive the encryption key from theZone 1 memory 912 and provide the decrypted data item to the Zone 1memory 912. In Zone 2, the first AES KW (D) HFG 964 is connected to theZone 2 bus 910 such that it can receive the encrypted data item from theZone 2 memory 914.

An AES KeyWrap encryption (AES KW (E)) HFG 966 bridges Zones 1 and 2 andis configured to encrypt a data item (e.g., one or more mission keys)from the Zone 1 memory 912 using an encryption key from the Zone 1memory 912 and to store the encrypted data item in the Zone 2 memory914. In Zone 1, the AES KW (E) HFG 966 is connected to the Zone 1 bus908 such that it can receive the data item and the encryption key fromthe Zone 1 memory 912. In Zone 2, the AES KW (E) HFG 966 is connected tothe Zone 2 bus 910 such that it can provide the encrypted data item tothe Zone 2 memory 914.

In some examples, a password port 970 facilitates direct entry of apassword into Zone 1 from outside of the device 900. In general, thepassword port 970 is only operational during the unlocking operationalphases of the device 900. In other examples, rather than or in additionto including the password port 970, the device 900 can internally storeor generate password-like data using, for example, a read only memory(ROM) 972 or a physical unclonable function (PUF) 974.

A secure password function (PBKDF2) HFG 968 bridges Zones 1 and 2 and isconfigured to create a cryptographic key (e.g., a key encryption key)using the output of the password port 970 (or the ROM or PUF) and a Saltfrom the Zone 2 Memory 914 and to store the cryptographic key in theZone 1 memory 912. In Zone 1, the PBKDF2 HFG 968 is connected to theoutput of the password port 970 and to the Zone 1 bus 908 such that itcan provide the cryptographic key to the Zone 1 memory 912. In Zone 2,the PBKDF2 HFG 968 is connected to the Zone 2 bus 910 such that it canreceive the Salt from the Zone 2 memory 914. As is the case with thepassword port 970, the PBKDF2 HFG 968 is only operational during theprovisioning and unlocking phases of the device 900.

A pseudo-random number generator (PRNG) module 976 is included in Zone 1and is configured to generate a pseudo-random number based on a seedvalue. The PRNG module 976 is connected to the Zone 1 bus 908 such thatit can receive the seed value from the Zone 1 memory 912 and provide thegenerated pseudo-random number to the Zone 1 memory 912.

A secure hash function (SHA) module 978 is included in Zone 1 and isconfigured to generate a secure hash value from a data item. The SHAmodule 978 is connected to the Zone 1 bus 908 such that it can receivethe data item from the Zone 1 memory 912 and provide the secure hash ofthe data item to the Zone 1 memory 912.

A true random number generator (TRNG) module 980 is included in Zone 1and is configured to generate a true random number based on, forexample, thermal noise, clock drift, atmospheric noise, or some otherrandom physical phenomena, for example, using a configuration ofoscillators whose frequencies and/or phases depend on the phenomena. TheTRNG module 980 is connected to the Zone 1 bus 908 such that it canprovide the generated true random number to the Zone 1 memory 912.

A symmetric key generator (Sym KeyGen) module 982 is included in Zone 1and is configured to receive a pseudo-random number and use thepseudo-random number to generate a symmetric cryptographic key (e.g., amission key). The Sym KeyGen module 982 is connected to the Zone 1 bus908 such that it can receive the pseudo-random number from the Zone 1memory 912 and provide the symmetric cryptographic key to the Zone 1memory 912.

An Elliptic Curve Digital Signature Verification (ECDSA (Verf)) module984 is included in Zone 2 and is configured to verify the authenticityof signed data. The ECDSA (Verf) module 984 is connected to the Zone 2bus 910 such that it can receive signed data. Based on the result of theverification, the ECDSA (Verf) module 984 may output a control signal(not shown) to notify other modules of the device whether they shouldproceed in processing the signed data.

An AES KeyWrap (AES KW) module 986 is included in Zone 2 and isconfigured to encrypt data (e.g., mission key metadata) in the Zone 2memory 914 using an encryption key from the Zone 2 memory 914 and tostore the encrypted data in the Zone 2 memory 914. The AES KW module 986is connected to the Zone 2 bus 910 sucht that it can receive the dataand the encryption key from the Zone 2 memory 914 and provide theencrypted data to the Zone 2 memory 914.

2.2 Device Operation

In general, the HFGs and hardware modules of the device 900 can beutilized in a wide array of ways according to the requirements of agiven application of the device. In some examples, a number ofprocedures can be used to initialize and use the device 900. Theseprocedures may include a secure boot procedure, an unlocking procedure,a provisioning procedure, a keywrap generation procedure, a keywrapunwrap procedure, and a data encryption/decryption procedure.

2.2.1 Secure Boot Procedure

Referring to FIG. 10, a simplified view of the device 900 illustratesthe secure boot procedure. In general, the secure boot procedure is aprocedure for verifying the authenticity of code (e.g., key managementsoftware) before loading the code onto and/or executing the code on aprocessor (e.g., a Tensilica processor in Zone 3) 988. Generally, abootloader 1094 verifies that code to be executed on the processor isauthentic before execution.

Initially, a code package 1092 is loaded into Zone 3 (e.g., from apersistent external memory source). The code package 1092 includes acode certificate (C_(C)), a code certificate signature (S_(CC)), a rootcertificate (R_(C)), a root signature (S_(R)), the code, and a codesignature (S_(C)). The code certificate includes a code public key (CPK)and the root certificate includes a root public key (RPK).

The bootloader 1094 stored, for example, on a ROM, is loaded onto theprocessor 988 which executes the bootloader to verify the code using theinformation included in the code package 1092. In a first step (1), theprocessor 988 provides the code certificate (Cc) to the SHA HFG 960which computes a secure hash of the code certificate (SHA(C_(C))) andstores the secure hash in Zone 2. In a second step (2), the secure hashof the code certificate (SHA(C_(C))), the root public key (RPK), and thecode certificate signature (S_(CC)) are provided to the ECDSA_(VERF)module 984 which verifies that the code certificate (C_(C)) is trusted.

In a third step (3), if the code certificate (C_(c)) is determined to beun-trusted, the secure boot procedure is aborted. Otherwise, if the codecertificate (C_(c)) is determined to be trusted, fourth step (4) isperformed in which a secure hash of the code (SHA(Code)) is computedusing a second SHG HFG 960′. The secure hash of the code (SHA(Code)) isstored in Zone 2. In a fifth step (5), the secure hash of the code (SHA(Code)), the code public key (CPK), and the code signature (S_(C)) areprovided to a second ECDSA_(Verf) module 984′ which verifies that thecode can be trusted. In a sixth step (6), if the code is determined tobe un-trusted, the secure boot procedure is aborted. Otherwise, if thecode is determined to be trusted, the code is executed using theprocessor 988.

2.2.2 Unlock Procedure

Referring to FIG. 11, a simplified view of the device 900 illustrates aprocedure for unlocking the device using a user-supplied password. Ingeneral, the unlock procedure readies the device for use by loadinglong-term keys and data into non-volatile memory on the device 900.

Initially, a persistent store key package (PKSP) including encryptedprivate data (E_(CEK)(PD)), an encrypted content encryption key(E_(KEK)(CEK)), and a Salt is loaded (e.g., from an external storagedevice) into Zone 3 by the processor 988. In general, the processor 988in Zone 3 handles all transfers of data into and out of Zone 2,including transfers of data from the PKSP into Zone 2.

The processor first copies the Salt, the encrypted content encryptionkey (E_(KEK)(CEK)), and the encrypted private data (E_(CEK)(PD)) intoZone 2. A high assurance controller (not shown) in the device then waitsfor a password to be entered through the secure password port 970. Whenthe password (PW) is received, a first step (1) is performed in whichthe PBKDF2 HFG 968 combines the Salt with the password (PW) to generatea key encryption key (KEK) which it stores in Zone 1.

In a second step (2), the key encryption key (KEK) in Zone 1 and theencrypted content encryption key (E_(KEK)(CEK)) in Zone 2 are providedto a first AES keywrap decryptor HFG 964 a which decrypts the encryptedcontent encryption key (E_(KEK)(CEK)) using the key encryption key (KEK)and stores the decrypted content encryption key (CEK) in Zone 1.

In a third step (3), the content encryption key (CEK) in Zone 1 and theencrypted private data (E_(CEK)(PD)) in Zone 2 are provided to a secondAES keywrap decryptor HFG 964 b which decrypts the encrypted privatedata (E_(CEK)(PD)) using the content encryption key (CEK) and stores thedecrypted private data (PD) in Zone 1.

In some examples, the private data includes root keys (RK) and a seedinitialization vector (IV) for use by the pseudo-random number generator(PRNG) 976. In a fourth step (4), the root keys (RK) are provided to thecontrolled transfer HFG 958 which passes the root keys (RK) into Zone 0where they are securely stored. In a fifth step (5), the seedinitialization vector (IV) is used as a seed for the PRNG 976. The PRNG976 generates a pseudo-random number which is combined (i.e., XORed)with a true random number generated by the true random number generator(TRNG) 980 to generate an updated seed initialization vector (IV′). Theupdated seed initialization vector (IV′) is used as the initial seedvalue for the next unlock operation. The initial seed value (IV) in theoriginal private data (PD) is overwritten using the updated initial seedvalue (IV′) resulting in an updated private data (PD′).

In a sixth step (6), the updated private data (PD′) and the contentencryption key (CEK) are provided to the AES encryption HFG 966 whichencrypts the updated private data (PD′) using the content encryption key(CEK), resulting in an encrypted version of the updated private data(E_(CEK)(PD′)). The processor 988 stores the encrypted version of theupdated private data (E_(CEK)(PD′)) off of the device for use in thenext unlock operation.

2.2.3 Provisioning Procedure

Referring to FIG. 12, a simplified view of the device 900 illustrates aprocedure for provisioning the device to generate an updated persistentstore key package (PSKP). In general, the provisioning procedure allowsfor modification of an existing PKSP to, for example, add or removeusers from the PKSP. To perform the provisioning procedure, the devicemust be started and the unlock procedure must have already beenperformed.

In a first step (1), the true random number generator (TRNG) 980generates a seed initialization vector (IV) in Zone 1. In a second step(2), the IV is provided to a first pseudo-random number generator (PRNG)976 a in Zone 1 which in turn generates a random number (RN). In a thirdstep (3), the random number (RN) is provided to the symmetric keygeneration module 982 which generates a content encryption key (CEK) anda number (e.g., 3) of root keys (K₀, K₁, K₃) in Zone 1.

In a fourth step (4), a new initialization vector (IV′) is determined inZone 1 by combining (e.g., XORing) the initialization vector (IV) andthe random number (RN). In a fifth step (5), the new initializationvector (IV′) and the root keys (K₀, K₁, K₃) are concatenated. In a sixthstep (6), the concatenation of the new initialization vector (IV′) andthe root keys (K₀, K₁, K₃) and the content encryption key (CEK) areprovided to a first AES keywrap encryption HFG 966 a which encrypts theconcatenation of the new initialization vector (IV′) and the root keys(K₀, K₁, . . . K_(N)) using the content encryption key (CEK) and storesthe encrypted result (E_(CEK)(K₀, K₁, K₃, IV′) in Zone 2.

In a seventh step (7), a second PRNG 976 b generates a proto-salt value(Proto-Salt) which is provided to the secure hash function (SHA) HFG 960which generates a Salt value (Salt) in Zone 2.

In an eighth step (8), the device 900 receives a password (PW) in Zone 1through the secure password port 970 and provides the password (PW),along with the Salt in Zone 2 to the secure password function (PBKDF2)HFG 968 which generates the key encryption key (KEK) in Zone 1. In aninth step (9), the content encryption key (CEK) and the key encryptionkey (KEK) are provided to a second AES encryption HFG 966 b whichencrypts the content encryption key (CEK) using the key encryption key(KEK) and stores the result (E_(KEK)(CEK)) in Zone 2.

Either during the provisioning operation or at the end of theprovisioning operation, the processor 988 writes appropriate values,including a user ID (UID), the Salt, the encrypted root keys andinitialization vector (E_(CEK)(K₀, K₁, K₃, IV′)), and the encryptedcontent encryption key (KEK) to the PSKP which is eventually stored offof the device.

2.2.4 Keywrap Generation Procedure

Referring to FIGS. 13 and 14, a simplified view of the device 900illustrates a procedure for generating a keywrap (e.g., an over-the-airkeywrap (OTAK), an over-a-wire keywrap, or a sneaker-net token) fordistribution of cryptographic information (e.g., mission or session keysand related metadata) to recipient devices (e.g., sources and sinks ofdata). In some examples, the keywrap includes a content encryption key(CEK) encrypted for each of the other recipient devices and an encryptedmission key package. To perform the keywrap generation procedure, thedevice must be initialized, had have at least one root certificate, atleast one signing key, and a key agreement key. In some examples, thesigning key(s) and the key agreement key(s) are delivered to Zone 0 ofthe device during the unlock procedure. In some examples, the keyagreement key(s) are ephemerally present in Zone 1.

Generally, the keywrap generation procedure, and an associatedunwrapping procedure described below, provide a way to combine data frommultiple security zones into a single data package in such a way thatwhen a recipient unwraps the data package, the data is redistributed tothe appropriate zones without violating the security policy. Therefore,for example, rather than treating keys and their associated metadata asuniform “key data”, which would conventionally be encrypted anddecrypted together, the keys may be encrypted separated from themetadata for those keys, such that access to the metadata in the keywrapdoes not necessitate access to the keys.

Referring to FIG. 13, in a first step (1), the pseudo-random numbergenerator (PRNG) 976 generates a random number which is used by thesymmetric key generation module 982 to generate one or more mission keys(Mission Keys) in Zone 1. In a second step (2), the PRNG 976 generatesanother random number which is used by the symmetric key generationmodule 982 to generate a content encryption key (CEK) in Zone 1. In athird step (3), the mission keys and the content encryption key (CEK)are provided to a first AES keywrap encryption HFG 966 a which encryptsthe mission keys using the content encryption key (CEK) and stores theresult (E_(CEK)(Mission Keys)) in Zone 2.

In a fourth step (4), the PRNG 976 generates a random number which isprovided to a first secure hash function (SHA) HFG 960 a. The SHA HFG960 a computes a secure hash of the random number, resulting in theUKM_(MPEK) nonce which is stored in Zone 2. In a fifth step (5), theUKM_(MPEK) nonce in Zone 2 and the content encryption key (CEK) in Zone1 are provided to a second SHA HFG 960 b which applies a secure hashfunction to the two values to compute a “black key” (BK) which it storesin Zone 2. It is noted that using a secure hash function is one of manypossible ways to derive the black key.

In a sixth step (6), mission key metadata, which is provided to Zone 2by the processor 988, and the black key (BK) are provided to an AESkeywrap encryption module 986 which encrypts the mission key metadatausing the black key (BK) and stores the result (E_(BK)(Mission KeyMetadata)) in Zone 2. In a seventh step (7),The encrypted mission keymetadata (EBK(Mission Key Metadata)) and the encrypted mission keys(ECEK(Mission Keys)) are provided to a third SHA HFG 960 c. The thirdSHA HFG 960 c computes a secure hash of the key update block (KUB)including the encrypted mission key metadata (EBK(Mission Key Metadata))and the encrypted mission keys (ECEK(Mission Keys)), resulting in a keyupdate block hash (SHA(KUB)) in Zone 2.

In an eighth step (8), the key update block hash (SHA(KUB)) in Zone 2, arandom value generated by the PRNG 976 in Zone 1, and a signing key inZone 0 are provided to the elliptic curve digital signing algorithm(ECDSA_(Sign)) HFG 956. The ECDSA_(Sign) HFG 956 creates a signature(SIG_(KUB)) for the KUB which it stores in Zone 2.

In a ninth step (9), another random value generated by the PRNG 976 isprovided to a fourth SHA HFG 960 d. The fourth SHA HFG 960 d applies asecure hash function to the random number to generate a UKM_(KA) noncein Zone 2. In a tenth step (10), another random number generated by thePRNG 976 is provided to the symmetric key generator 982 which generatesan ephemeral private key (EK_(Pri)) in Zone 1. In an eleventh step (11),the ephemeral private key (EK_(Pri)), the UKMKA nonce, “other info”provided by the processor, and a recipient's public key (RPK) areprovided to the elliptic key diffie-hellman (ECDH) HFG 954 whichgenerates a key encryption key (KEK) in Zone 1 from its inputs.

In a twelfth step (12), the key encryption key (KEK) and the contentencryption key (CEK) are provided to a second AES keywrap encryption HFG966 b. The second AES keywrap encryption HFG 966 b encrypts the contentencryption key (CEK) using the key encryption key (KEK) resulting in anencrypted content encryption key (E_(KEK)(CEK)) in Zone 2. A unique ID(UID) provided by the processor 988 is associated with the encryptedcontent encryption key (E_(KEK)(CEK)). In some examples, multiple (e.g.,32) UID/E_(KEK)(CEK) pairs are generated for multiple recipients.

In a thirteenth step (13), another random number generated by the PRNG976 is provided to the public key generation HFG 962 which generates anephemeral public key (EK_(Pub)) in Zone 2.

Referring to FIG. 14, a continuation of the keywrap generation procedureis illustrated. Note that the bolded items (i.e., the bolded ovalshapes) in FIG. 13 are reproduced in FIG. 14.

In a fourteenth step (14), the ephemeral public key (EK_(Pub)), theUKMKA nonce, the UKMMPEK nonce, the user identification(s) (UID), theencrypted content encryption key(s) (EKEK(CEK)), the encrypted missionkey metadata (EBK(Mission Key Metadata)), the encrypted mission keys(ECEK(Mission Keys)), and the KUB signature (SIG_(KUB)) are bundled intoa keywrap 961 in Zone 2. The keywrap 961 is provided to a fifth SHA HFG960 e which computes a secure hash of the keywrap (SHA(KeyWrap)) in Zone2.

In a fifteenth step (15), the secure hash of the keywrap (SHA(KeyWrap))and the signing key in Zone 0 are provided to the ECDSA signing module956 which computes a signature of the secure hash of the keywrap(SIG_(KWHash)).

The keywrap 961 and the signature of the secure hash of the keywrap(SIG_(KWHash)) are provided to the processor 988 which appends asender's certificate (C_(S)) 963 to the keywrap 961 and the signature ofthe secure hash of the keywrap (SIG_(KWHash)) before transmitting thekeywrap from the device 900.

Note that as described above, the mission keys are encrypted by acontent encryption key (step 3), both of which are restricted to Zone 1,while the metadata is encrypted by a secure hash of the contentencryption key (referred to as the “black key” above) according to steps(5) and (6). Therefore, only the secure hash of the content encryptionkey is needed in Zone 2 to decrypt the metadata, thereby maintaining theZone 1 security of the mission keys in the keywrap.

In some examples, certain items in the keywrap are collectively referredto as a “header.” In some examples, the header includes informationnecessary to decrypt the content encryption key. In some examples, theheader includes a key agreement key, a password, a symmetric key, and soon.

2.2.5 Keywrap Unwrap Procedure

Referring to FIGS. 15 and 16 a simplified view of the device 900illustrates a procedure for unwrapping a keywrap (e.g., the keywrapgenerated in FIGS. 14 and 15) to access the cryptographic informationcontained therein. In general, the keywrap unwrap procedure occurs at arecipient device which receives a keywrap from a sender device andstores the keywrap in its Zone 3. Unless otherwise noted, data from thekeywrap is read from Zone 3 into Zone 2 via the processor 988 as needed.

In a first step (1), the sender's certificate (C_(S)) is provided to afirst secure hash function (SHA) HFG 960 a which computes a secure hashof the sender's certificate (SHA(C_(S))) and stores it in Zone 2. In asecond step (2), the validity of the sender's certificate (C_(S)) isverified by providing the secure hash of the sender's certificate(SHA(C_(S))), the signature of the sender's certificate (SIG_(CS)), andthe root public key (RPK) associated with the sender's certificate to afirst elliptic key digital signature verification module (ECDSA_(Verf))984 a. If the first ECDSA_(Verf) module 948 a indicates that thesender's certificate is invalid, then the key unwrap procedure isaborted. Otherwise, the key unwrap procedure continues.

In a third step (3), the keywrap (KW) 963 is provided to a second securehash function (SHA) HFG 960 b which computes a secure hash of thekeywrap (SHA(KW)) and stores it in Zone 2. In a fourth step (4), thevalidity of the keywrap hash signature (Sig_(KWHash)) is verified byproviding the secure hash of the keywrap (SHA(KW)), the keywrap hashsignature (Sig_(KWHash)), and the public key of the sender's certificate(PK_(CS)) to a second ECDSA_(Verf) module 984 b. If the secondECDSA_(Verf) module 948 b indicates that the keywrap signature(Sig_(KWHash)) is invalid, then the key unwrap procedure is aborted.Otherwise, the key unwrap procedure continues.

In a fifth step (5), the key update block (KUB) including the encryptedmission keys (E_(CEK)(Mission Keys)) and the encrypted mission keymetadata (E_(BK)(Key Metadata)) is provided to a third secure hashfunction (SHA) HFG 960 c which computes a secure hash of the key updateblock (SHA(KUB)) and stores it in Zone 2. In a sixth step (6), thevalidity of the key update block signature (Sig_(KUB)) is verified byproviding the secure hash of the key update block (SHA(KUB)), the keyupdate block signature (Sig_(KUB)), and the public key of the sender'scertificate (PK_(Cs)) to a third ECDSA_(Verf) module 984 c. If the thirdECDSA_(Verf) module 948 c indicates that the key update block signature(Sig_(KUB)) is invalid, then the key unwrap procedure is aborted.Otherwise, the key unwrap procedure continues.

Referring to FIG. 16, a continuation of the key unwrap procedure isillustrated. In a seventh step (7), the key agreement key (KAK) in Zone0, the ephemeral public key (EK_(Pub)) in Zone 2, the UKM_(KA) nonce inZone 2, and the “other info” in Zone 2 are provided to the elliptic keyDiffie-Hellman key generation (ECDH) HFG 954 which uses its inputs togenerate a key encryption key (KEK) in Zone 1.

In a eighth step (8), the encrypted content encryption key(E_(KEK)(CEK)) (matching the UID of the device) in Zone 2 and the keyencryption key (KEK) in Zone 1 are provided to a first AES keywrapdecryption HFG 964 a which decrypts the encrypted content encryption key(E_(KEK)(CEK)) using the key encryption key (KEK) resulting in adecrypted content encryption key (CEK) in Zone 1. In an ninth step (9),the encrypted mission keys (E_(CEK)(Mission Keys)) in Zone 2 and thecontent encryption key (CEK) in Zone 1 are provided to a second AESkeywrap decryption HFG 964 b which decrypts the encrypted mission keys(E_(CEK)(Mission Keys)) using the content encryption key (CEK) resultingin decrypted mission keys (Mission Keys) being stored in Zone 1.

In a tenth step (10), the content encryption key (CEK) in Zone 1 and theUKM_(MPEK) nonce in Zone 2 are provided to a fourth SHA HFG 960 d whichcomputes a secure hash of the content encryption key (CEK) and theUKM_(MPEK) nonce resulting in a black key (BK) in Zone 2. In an eleventhstep (11), the black key (BK) and the encrypted key metadata (E_(BK)(KeyMetadata)) are provided to an AES keywrap decryption module 986 whichdecrypts the encrypted key metadata (E_(BK)(Key Metadata)) using theblack key (KB) resulting in decrypted key metadata (Key Metadata) inZone 2.

In some examples the key metadata is used by the processor 988 todetermine how the mission keys are organized in the Zone 1 memory.

Note that exchanging keywraps between devices enables establishingshared secrets (e.g., keys) and mutual authentication betweencorresponding zones in the devices, thereby logically extending a zoneof one device with that corresponding zone of the other device.

3 Verification

In general, the circuitry of the hardware functional gates and thecircuitry of the security zones are specified in software using, forexample, a hardware description language. The software specification isused to automatically lay the circuitry out on a device such as an FPGA.Advantageously, verification of the security properties of the hardwarefunctional gates and the security zones can be carried out entirely bystatic analysis of the software specification of the device withoutrequiring any inspection of the laid out design.

For example a human or a static analysis computer program can analyzethe software specification of the device to ensure that the circuitryrelated to data paths of the different security zones is mutuallyexclusive. That is, the circuitry related to data paths of a givensecurity zone is not connected to the circuitry related to data paths ofanother different security zone except via rigorously verified gatecircuitry. Similarly, a human or static analysis computer program cananalyze the software specification of the device to ensure that thehardware functional gate circuits abide by their respective securitypolicies (i.e., the hardware functional gate circuits do not allow forleakage of data between zones).

4 Applications

The key management and cryptography device 900 described above can beused in a wide variety of applications, for example, where securecommunication or identity management is required. Referring to FIG. 17,one example of an application utilizing the key management andcryptography device 900 includes a pair of key fobs (e.g., USB key fobs)1782, 1784 which can be used to establish a secure network communicationsession between two computers 1786, 1788 over a communication network(e.g., the internet) 1787. Each of the key fobs includes an instance ofthe key management and cryptography device 900 a, 900 b.

In general, in operation, each of the key fobs 1782, 1784 is firstplugged into its respective computer 1786, 1788. Respective users (notshown) associated with the key fobs 1782, 1784 unlock the key fobs byentering passwords which are transmitted to the key management andcryptography devices 900 a, 900 b of the key fobs. In some examples, theusers can enter their passwords by swiping their fingers overfingerprint readers 1790, 1792. In other examples, the users can entertheir passwords by typing their passwords using keyboards connected tothe computers 1786, 1788. Once unlocked, the key management andcryptography devices 900 a, 900 b can exchange cryptographic informationvia keywraps (as described above) to establish shared keys (e.g., sharedkeys in respective zone l's) for secure communication channel betweenthe two computers. All secure information passed between the twocomputers is then encrypted/decrypted by the key management andcryptography devices 900 a, 900 b using the cryptographic keys managedby the devices 900 a, 900 b.

Referring to FIG. 18, another example of an application utilizing thekey management and cryptography device 900 includes two secure telephoneunits 1892, 1894, each connected to a respective telephone handset 1896,1898. The secure telephone units 1892, 1894 are each connected to acommunication network 1806 via, for example, a wireless connection 1808,1810, or a wired connection 1802, 1804. Each of the secure telephoneunits 1892, 1894 includes an instance of the key management andcryptography device 900 a, 900 b which together establish a securecommunication channel between the two secure telephone units 1892, 1894.

In general, respective users (not shown) associated with the securetelephone units 1892, 1894 can unlock the secure telephone units byentering a password which is transmitted to the key management andcryptography devices 900 a, 900 b in the secure telephone units. In someexamples, the users can enter their password by typing it into theirhandset. Once unlocked, the key management and cryptography devices 900a, 900 b exchange cryptographic information via keywraps (as describedabove) to establish mutual authentication and shared keys for securecommunication channel between the secure telephone units. All secureinformation passed between the two secure telephone units is thenencrypted/decrypted by the key management and cryptography devices 900a, 900 b using the cryptographic keys managed by the devices 900 a, 900b.

Referring to FIG. 19, another example of an application utilizing thekey management and cryptography device 900 includes two secureprocessors 1902, 1904 each connected to a network 1906 (e.g., a localarea network (LAN)) through a network interface 1908, 1910. The secureprocessors 1902, 1904 wish to securely communicate with one another overthe network. Each of the secure processors 1902, 1904 includes a numberof general purpose processors 1912, 1914 and a key management andcryptography device 900 a, 900 b. In this example, the each of the keymanagement and cryptography devices 900 a, 900 b includes a passwordread only memory (ROM) (not shown) which stores its respective passwordfor unlocking purposes. When the secure processors boot, theirrespective key management and cryptography devices unlock themselves byreading the password from their respective password ROMs. Once unlocked,the key management and cryptography devices 900 a, 900 b can exchangecryptographic information via keywraps (as described above) to establisha secure communication channel between the secure processors. All secureinformation passed between the two secure processors must beencrypted/decrypted by the key management and cryptography devices 900a, 900 b using the keys managed by the devices 900 a, 900 b.

Referring to FIG. 20, another example of an application using the keymanagement and cryptography device includes a number of unmanned aerialvehicles (UAVs) 2000 and a number of ground based stations 2006 (e.g.,handheld computers, laptops, and so on), each having an on-board keymanagement and cryptography device 900 (not shown), and a centralizedcontrol station 2002 in communication (e.g., radio communication) withthe UAVs. The control station 2002 creates keywraps 2004 and distributesthe keywraps to the UAVs and the ground based stations.

In some examples, the keywraps enable the UAVs and the ground basedstations to communicate securely with the control station and with eachother. In some examples, the keywraps authorize or prohibit certainground based stations access to a downlink 2008 from one or more of theUAVs. In some examples, the downlink 2008 includes video data or othersensor data which is consumed by authorized ground based stations. Insome examples, the keywraps authorize or prohibit certain ground basedstations' access to weapons systems on the UAVs.

In some examples, the control station directly provides keywraps to boththe UAVs and the ground based stations. In other examples, keywraps areprovided to the UAVs which relay the keywraps to the ground basedstations.

In some examples, the control station 2002 distributes cryptographickeys to the group of UAVs to secure the group's communication (e.g.,secure multicast). In some examples, the control station 2002distributes cryptographic keys on-the-fly to authorized devices (e.g.,aerial vehicles and ground terminals).

In some examples, multiple control stations are present and the keymanagement and cryptography devices are used to facilitate communicationhand-off between the control stations. In some examples, the keymanagement and cryptography devices are used to establish relays amongmultiple UAVs (e.g., to communicate over long distances).

In other examples, the key management and cryptography device can beused to establish secure vehicular networks, secure sensory networks,secure utility sensor networks, secure industrial automation, andend-to-end protected data storage in a cloud.

In some examples, the control station is a secure key server whichgenerates keywraps but does not necessarily include the key managementand cryptography device.

In some examples, the system described above can be used to establishsecure communication channels between other unmanned systems such asdrones (e.g., remotely piloted aircraft, unmanned aircraft systems, andso on).

Alternatives

In some examples, HFGs read inputs from a first zone and place outputsin a second, different zone. In other examples, HFGs read inputs from afirst zone and place outputs in the first zone (i.e., the same zone).

In some examples, the security architecture is manifested as hardwarehaving physical separations and explicit interconnections. Thiseliminates the reliance on logical controls and logical guards.

In some examples, the architecture of the device is optimized afterdesign and verification of the device is complete. Optimization mayinclude consolidation of replicated functions and/or addition ofadditional security measures such as multiplexing of signals and data ina controlled manner to meet security requirements. For example, a singlekeygen function that takes as input a destination zone could be used toreplace multiple, zone-specific keygen functions.

In the examples described above, all encryption and decryptionoperations are described as using AES encryption and decryptionalgorithms and Elliptic Curve Cryptography (ECC). However, it is notedthat the device is not limited to using AES and ECC cryptographyalgorithms and is capable of using any suitable cryptography algorithms.

In some examples, the design of the key management and cryptographydevice is optimized to reduce complexity, merge security zones, or otheroptimizations without compromising the security of the device.

In some examples, the key management and cryptography device is usedboth as a producer and consumer of keywraps. In other examples, keywrapsare produced by a secure device which does not necessarily include thekey management and cryptography device. For example, a key managementserver may provide keywraps to clients to facilitate access to data(e.g., retrieved from a cloud service). In another example, a key serverwhich does not necessarily include the key management and cryptographydevice can distribute group keys using an advanced tree-based keyingscheme in a scalable group keying scheme.

In some examples, other types of hardware functional gates exist. Forexample, a hardware functional gate with internal storage wherein theinternal storage bridges two security zones.

While in the examples above, a secure hash function is used to, forexample, create keys in Zone 2, it is noted that other types ofnon-invertible, one way functions can be used in place of the securehash function.

6 Implementations

Systems that implement the techniques described above can be implementedin software, in firmware, in digital electronic circuitry, or incomputer hardware, or in combinations of them. The system can include acomputer program product tangibly embodied in a machine-readable storagedevice for execution by a programmable processor, and method steps canbe performed by a programmable processor executing a program ofinstructions to perform functions by operating on input data andgenerating output. The system can be implemented in one or more computerprograms that are executable on a programmable system including at leastone programmable processor coupled to receive data and instructionsfrom, and to transmit data and instructions to, a data storage system,at least one input device, and at least one output device. Each computerprogram can be implemented in a high-level procedural or object-orientedprogramming language, or in assembly or machine language if desired; andin any case, the language can be a compiled or interpreted language.Suitable processors include, by way of example, both general and specialpurpose microprocessors. Generally, a processor will receiveinstructions and data from a read-only memory and/or a random accessmemory. Generally, a computer will include one or more mass storagedevices for storing data files; such devices include magnetic disks,such as internal hard disks and removable disks; magneto-optical disks;and optical disks. Storage devices suitable for tangibly embodyingcomputer program instructions and data include all forms of non-volatilememory, including by way of example semiconductor memory devices, suchas EPROM, EEPROM, and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM disks. Any of the foregoing can be supplemented by, orincorporated in, ASICs (application-specific integrated circuits).

In some implementations, a circuit conforming to the approachesdescribed above is specified as stored configuration data on anon-volatile computer-readable medium for a configurable device thatimparts functionality onto a device, for instance, as “personality data”for a Field Programmable Gate Array. In some examples, the HFG areprovided as a library of selectable configuration data that is used toassemble an overall device using conventional configuration tools. Insome examples, the circuitry is specified in a Hardware DescriptionLanguage (HDL), for instance Verilog statements and instructions storedon a non-volatile computer-readable medium, such that a circuitconforming to the security architecture can be made according to thespecification, for example, using automated layout and fabricationtechniques. In some examples, the HFG are provided as a library ofmodules, which may be incorporated into an overall circuit design, suchthat the security of the overall design may be verified (e.g., byautomated tools).

It is to be understood that the foregoing description is intended toillustrate and not to limit the scope of the invention, which is definedby the scope of the appended claims. Other embodiments are within thescope of the following claims.

What is claimed is:
 1. A method for establishing group key data among aplurality of secure devices, each secure device having a plurality ofmutually exclusive circuit zones, including a first circuit zone havinga first level of security and a second circuit zone having a secondlevel of security less than the first level of security comprising:receiving the key exchange package in a second circuit zone of each ofthe secure devices, the key exchange package including encrypted keydata; establishing a shared key data in the first circuit zone of eachof the secure devices including, for each of the secure devices,processing the encrypted key data using a content key to generatedecrypted key data and storing the decrypted key data in the firstcircuit zone of each of the secure device without disclosing the contentkey into the second circuit zone of the secure device; securelyexchanging messages between the secure devices, the messages beingprocessed by the shared key data.
 2. The method of claim 1 furthercomprising distributing the key exchange package from a secure computerserver.